DevOps integration with Team Foundation Server

John

DevOps

Dev + Ops = Delivery and support of software

  • Dev and Ops work closely together
  • Use of automation
  • Build
  • Test
  • Deploy
  • MonitoringInfrastructure (like use of containers / docker)Frequent ReleasesQuick testing
  • Creates predictability and consistency (a delivery every 30 days)
  • Define what DONE means
  • Works in smaller chunks prioritizes the backlog

 

TFS and Team

Services are nearly Identical

  • Version Control
    • Git
  • Project Management
    • Scrum, agile
    • Defect tracking
  • QA Testing / Test Case management
  • Automation
  • Build
  • Release

 

Version Control

TFVC (Team Foundation Version Control) vs Git

Centralized vs Distributed

Team Projects

Team Project is a container for all “stuff” for software development effort. Could be one team on one project, or multiple teams on multiple projects. Best practice is to keep fewest number of team projects.

Projects has a version control (tfvc, git) and process template (scrum, agile, cmmi). Team Projects can be created through the webui or vs.

Team Project Collections (TPC) = collection of team projects. Collections are all about storage and how they are stored in SQL server. Everything in the same TPC can share code and reference work items between Team Projects.

Best practice = use only one TPC. By default, use the DefaultCollection TPC. On the database, it is stored as Tfs_DefaultCollection.

Note that a Team Project may have one or many repositories.

 

Work Constraints

Four types of Work in IT

  • Business Projects (makes money)
  • Internal IT Projects (not make money but still important)
  • Changes
  • Unplanned Work

Dangers

  • Untracked work
  • Work not tracked in same way
  • Hidden work
  • Unplanned work
  • Drop everything and fix work

 

Multitasking

Things that slow you down

  • Multitasking
  • Everything is “In Progress”
  • Constraints / Bottlenecks
  • The more you multitask, the more waste there is.

Working without multitasking in teams may mean that some members will occasionally be under-utilized, but the team overall will work faster due to a higher focus. This leads to continuous delivery.

Theory of Constraints

Having a team member that is overly busy and requires items to wait before they can address it can cause exponential Wait Time for the whole team and project. Wait Time = busy time / idle time

Theory of Constraint = removing the constraints will increase performance speed significantly

  • Identify the constraint
  • Exploit the constraint (make sure they do work right the first time)
  • Subordinate all other activities to the constraint (avoid giving constraint more than can handle)
  • Elevate the constraint to new levels
  • Find the next constraint

 

 

Planning and Tracking Your Teams Work

Scrum and Kanban

 

Product Backlog Item (PBI)

Feature = Epic

Backlog Item (PBI) = Story

Add a pbi to a feature by dragging and drop it into the feature.

Each PBI has an effort field should use Story Points (1,2,4, etc)

 

Forecasting and Velocity

Velocity = how many story points can be burned down in a sprint. The velocity graph is shown on the top right of page.

Turn on Forecast View to see the forecast:

Once the velocity value is established, TFS will automatically apply it to forecast (if turned on above) and show in which sprint each of the PBI will be resolved:

 

Sprint Planning

Drag and drop PBI into the sprint. You can see it in the sprint by the column value:

Set the Sprint start and end dates.

 

Capacity

How much work each team member can contribute to.

PBI can be set to each individual member and youll see how much that that member can take based on their capacity. You can also see the overall team capacity and the hours estimated for the overall sprint.

 

Settings

Customize styles (highlights, colors, etc)

Customize fields Burndown Chart

 

Project Dashboard

Add/Remove widgets. Edit widgets. Everything is tile based so you can set the location and size of each widget. Can also add new dashboards

Can also create widgets that show different query results. Queries can be customized to pull whatever data needed. Queries can also be used to create charts. These charts can be added to the dashboard.

 

Unit Testing and DevOps

Unit test = code that never gets deployed but tests code that does get deployed. It verifies low level features or functions.

In visual studio create Unit Test projects.

Unit tests follow this structure

  • Arrange = setup the test
  • Act = run the test
  • Assert = verify the test

 

 

Testing is Layered

QA Tests are manual (usually) done by people. QA is a limited resource. As such, this is most expensive. The Unit Tests are cheap and should catch a majority of the issues. So focus on having good Unit Tests.

In DevOps, we try to skip the QA step as much as possible. QA is expensive and causes slow down (is a constraint). So instead focusing on unit tests will help speed up the process.

The more that Testing becomes automated, the actual QA testing actually changes its paradigm. Instead of doing test cases (which can be automated), they can do exploratory testing. This is more valuable as it goes beyond the original design and really checks the application in many different/new angles.

 

 

Automating Builds and Deployments

Benefits of automation
Solves the works on my box problem the following are addressed:

  • Integration issues
  • Configuration
  • Code differences
  • Version issues

The slight differences can accumulate to be significant in production and make it difficult to see whats wrong
The integration gives bottom line answer for Is the build broken?

  • Build check
  • Unit Test check
  • Gives frequent deployments
  • Problems can be caught quickly
  • Users can test features quickly

Integration becomes less painful since constantly integrating

 

 

Creating TFS Build

Two different types of builds in TFS

  • XAML
  • All Build Definitions

Create a new build definition

  • Xamarin (iOS, Android)

Can build from a remote repo

Every build gets a build ID, console, logs, results

Build summary

Can view the Artifacts which are the resulting files from the build:

 

Running Tests

TFS runs unit tests. It is configured in the Visual Studio Test section of the build configuration. Give it a location to the test assembly. The assembly file should have the word test in it:

Note that if you have different tests (like unit test and integration test), make sure to specific those assembly names. The Run in Parallel = does multithreaded execution of unit tests (makes it faster but make sure its ok to use multithreads).

The Code Coverage Enabled will show how much of the code base is tested in the build results:

Want to keep this number somewhat high.

 

Triggers

How a build is triggered. Can setup CI here. Can also do scheduled builds. The CI option means to run build whenever a change is commited to the set branch.

 

Build Failures and Bugs

Can see build results through Team Explorer on Visual Studio. On the build definitons go to Options and can create auto generation of a ticket on build failure. Have it assigned to whomever did the last checkin.

Can also create issue tickets when a unit test fails. This can be done manually.

 

Builds and Project Dashboard

 

Build Agents

Agents do the build and can have custom capabilities

This can be configured in the Manage Project agents are defined at the Team Project Collection level

Agents have different capabilities. Custom capabililties can be added.

Then from the build definitions, can create demands that check for some of the agent capabilities. Based on what agents can meet those build demands, it will use that agent.

 

Auto Deploy Database Updates on Build

In the build definition, add a Visual Studio Test step. Notice the step order is controlled by this list

Look at the sample build script on site: deploy-to-sql-server.ps1

 

 

Auto Deploy to IIS

Things to be done in the build definiton

  • Create directory on web server
  • Copy code to web server
  • Create App in IIS
  • Modify the web.config

In the build definition, look at the Build

The following command will publish to the directory

This will drop all the deploy files in the for-deploy folder

To deploy those files to IIS, run following script.

We also want to update the connection on deploy. This can be done by have a Command Line step.

Under the build vairables, can also add the following connection string information

The script being called will now edit the web.config with the variables set above.

Lastly we want to deploy all the files from the build to the IIS server. This is another copy files step

Last step is to have IIS run a powershell script. The step is a PowerShell on Target Machines. You need to credentials on server to run this on that server.

 

 

QA Testing and Automated UI Tests with Coded UI

DevOps blurs the line between Dev and Ops. DevOps allows developers to do some of the QA tests. Some of the test plans should be defined early so that developers can run them during their work. Use Microsoft Test Manager.

In TFS go to Test

 

There are different types of test cases that can be created within a test plan.

Requirement based suite creates test cases by a backlog item / story. In the test case, add information about the steps for the test.

Another way to enter test cases is through the grid, which is kind of a bulk entry

Can also test case parameters, which may include test data that is to be used.

To run the tests, right click on the test case and select run

Example of how a QA may run the test manually. They have both the test case list and the actual application.

From the test steps, if something fails, the QA may create a bug item right then. (link above).

Example of chart that summarizes all the test cases

 

 

Microsoft Test Manager (MTM)

MTM has a few more features that is missing on the web interface.

 

 

Automate the UI Tests

The following test types can be automated through TFS

UI tests are somewhat difficult to create as you are trying to work with the tool to make a sequence of actions happen. This sequence often have a lot of exceptional cases, which makes it difficult to write and can become a maintenance problem over time. UI automation tests should be used sparingly. Unit tests have far better ROI than UI tests.

 

UI
automation tests are most difficult to maintain so this should be the fewest tests make them focused on specific items and not across the board. Some good judgement needed up front to determine what UI tests will be automated.

The automation UI tests will flow through the test cases and take screen shots: